昨天我們看過網站背後的架構圖。今天先不急著把裡面的東西全部接起來，想先問大家一個問題：

「我們常說把網站放上雲端，但這個『雲端』，到底在哪裡？」

寫程式的時候，你知道程式跑在自己的電腦上。但把電腦關掉之後，如果還希望別人隨時都能使用網站，就需要另一台電腦持續執行網站程式。

這種負責提供網站服務的電腦，我們通常會叫它「主機」。

你可以自己準備機器，也可以使用雲端業者提供的主機。這個系列會介紹的 AWS，就是 Amazon 提供的雲端服務平台。

今天的主角：Region（區域），決定主機放在哪裡

雖然叫「雲端」，背後仍然有實體機器，需要地方放它們、供電和連上網路。你把程式交給雲端主機執行，程式還是在世界上的某個地方跑著。

AWS 在世界上不同地點建置這些設施，並劃分出不同的地理區域。這些區域就叫做 Region，也是我們今天要認識的主角。

例如日本東京與美國維吉尼亞北部，就是兩個不同的 Region。維吉尼亞州在美國東部，和日本隔著一整個太平洋；你選哪一個區域建立主機，就是在決定這台主機放在哪裡。

那是不是離自己最近的主機就是最好呢？不用急，後面會介紹你要如何評估主機放置規則 :D

把世界地圖攤開來看，就更容易理解了。我先挑幾個 Region 標出來，你可以從熟悉的臺北、東京往外看，看看它們分布在世界上的哪些地方。

圖上的圓點是地理位置示意，沒有列出全部 Region，也不是機房地址。各區域的所在地與完整清單，可以看 AWS 官方 Region 清單（2026 年 9 月 10 日查閱）。

所以，當你跟同事說「我把網站放上 AWS 了」，其實還沒交代完主機的位置。需要再補充「主機建立在東京 Region」，對方才知道你選的是哪個地點。

今天要學的，就是先看懂 Region 代表的地理位置，再練習判斷：這個位置適不適合我的網站？

Region 跟 AWS 的「服務」，有什麼關係？

知道了地點，接著還要知道：我們打算在這裡使用什麼？

AWS 提供很多不同用途的工具與功能，讓你依照網站的需要選用。這些就是我們接下來會一直提到的「AWS 服務」。

舉兩個跟網站很有關係的例子：

你需要一台電腦來跑程式，可以使用 Amazon EC2。先把它想成向 AWS 租用一台能透過網路管理的電腦，你可以在上面安裝軟體、執行網站程式，不必自己買機器放在家裡。它背後的硬體由 AWS 提供。EC2 的官方介紹就在說明這項服務。

如果你目前只寫過前端，這裡先分清楚兩邊的工作：送到使用者那裡的 HTML、CSS，以及寫給瀏覽器執行的 JavaScript，仍由瀏覽器處理；接收註冊請求、保存會員資料等工作，則可以交給主機上的程式。後面這種程式，我們會叫它後端程式。今天租 EC2，就是替這些工作準備一台主機。

如果會員註冊後，要收到一封驗證信，AWS 也有 Amazon SES 這個寄信服務。在這個例子裡，瀏覽器先把註冊請求送給後端，再由主機上的後端程式請 SES 寄信，不必從頭自己架設寄信主機。它仍需要設定與程式串接，不是把網站放到 AWS，驗證信就會自己寄出去。SES 的官方介紹有列出它的用途。

先看懂這兩件事就好：EC2 讓後端程式有一台電腦可以執行，SES 則協助它寄信。

後面遇到新的服務名稱，我們也會用同樣的方法，先看看網站遇到了什麼問題，再認識 AWS 的各種服務中，是否能幫上什麼忙。

在東京 Region 建立一台 EC2 主機

假設今天你要替網站準備一台主機，就可以把需求說成：「我要使用 EC2，而且要在東京 Region 建立這台主機。」

前半句的 EC2，交代了你要用哪項服務；後半句的東京 Region，交代了主機要建立在哪裡。

服務是在選「我要使用什麼功能」，Region 則是在選「我要在哪個地理區域使用它」。

同樣是租一台 EC2 主機，建立在東京，或建立在美國維吉尼亞北部，選的服務可以相同，主機的位置卻不同。這就是為什麼光決定「我要用 EC2」還不夠，我們還得想想 Region 怎麼選。

Region 怎麼選？使用者在臺灣，就選日本嗎？

假設今天的會員網站，第一批使用者主要都住在臺灣。

「那我們就把主機放東京吧，比起美國，離臺灣近多了，應該比較快？」

我覺得這是一個很自然的起點。不過，要決定之前，還有幾件事可以一起確認。

這裡有我要用的功能嗎？

剛才提到，網站可能需要主機，也需要寄驗證信。

AWS 的服務與功能，並不一定在每個 Region 都同樣提供。因此要先確認：打算使用的主機、寄信等服務，在考慮的區域能不能用到需要的功能。

拿離我們最近的臺北來說，就有一個很實際的例子。

臺北 Region 有提供 EC2 主機，但截至 2026 年 9 月 15 日查閱 AWS 官方清單，我去看服務列表中，SES 的寄信服務區域有東京，尚未列出臺北。 可以對照 EC2 各區域支援清單與 SES 區域清單。

「咦，所以我的主機放臺北，就不能寄驗證信了嗎？」

主機放臺北，還是可以透過網路連到東京等有提供 SES 的區域，請那裡的服務協助寄信。這是依 SES 透過區域連線位址寄信的方式延伸的安排；寄信設定也要在選好的 SES 區域完成。

不過，如果假使你的客戶有規定「第一版的主機和寄信服務都要放在同一個 Region」，臺北就不符合這個安排了。此時要找同時提供所需服務的地點，再確認其他條件。

舉這個例子只是想大家分享，光是多一句「服務要放在同一區」，選擇就不一樣了。先確認我們要做什麼、有哪些限制，才知道要查哪份資料。

會員資料可以放在這裡嗎？

這個我就很常遇到。客戶會說：「主機可以上雲，但務必要在臺灣，放到其他地方就會違約。」

聽到這句話，就不能只拿著一張價目表說：「可是放美國比較便宜耶！」

因為客戶已經把能選的範圍講出來了。在這份合約的要求下，主機留在臺灣是一定要做到的事。 國外的方案再便宜、連線再快，都不能直接拿來替換。

不過，這裡還要多問清楚一點：對方要求的是「主機在臺灣」，還是「會員資料也必須留在臺灣」？備份的資料、寄信時交給其他服務的資料，有沒有一起限制？

想像你把網站主機放在臺北，卻把會員資料存到國外。主機的位置符合了，不代表資料的位置也符合。所以要照實際合約，把受限制的東西逐一確認，不能只看到主機在臺灣就收工。

前面說的「臺北主機請東京 SES 寄信」，也是一樣。技術上能連過去，還得確認這個安排是否符合客戶對資料的要求，不能直接套用。

這是我遇到的客戶條件，每個案子要確認的內容可能不同。先把對方的「一定要」問清楚，才知道剩下哪些方案可以繼續比較。

費用能接受嗎？

換個情境，假設你只是想先做一個小型活動報名網站，看看有沒有人願意用。

第一版能註冊、收驗證信、報名活動就好，其他功能之後再說。這種先用最少的必要功能驗證想法的版本，常會叫做 MVP，也就是「最小可行產品」。

這時你可能會想：「都還不知道有沒有人用，我不想一開始就花太多錢啊 XD」

很合理。如果需要的功能都有、資料位置符合要求、使用起來也在能接受的範圍內，那麼費用比較低的方案，就可以是這一階段的首選。不用為了追求每一項都最好，把第一版的預算全花光。

但在比價格之前，要先確認兩邊算的是同一件事。例如相同的主機需求、預估會員人數與寄信量，再把會用到的費用一起算進去。一邊只算主機，另一邊連資料保存和寄信都算了，放在一起比就不公平。

還有一句話也要問清楚：「每個月最多花 US$30」和「請找最便宜的」，是兩種不同的要求。

舉個假設的數字，一個方案每月 US$24，另一個 US$20，兩個都沒超過 US$30。若你說「這版先省錢」，就比較哪個費用低；若你說「預算內，讓會員少等一點」，就要接著看連線表現。

光知道預算上限，還不知道你比較在意什麼。把這句話補完整，選擇才會有依據。

說「比較快」，到底要看什麼？

先想像你現在人在臺灣，點開一個網站。

主機放在東京，訊息得從臺灣送到日本，再把回應送回來；主機放在美國東部，通常就得走更遠的距離。訊息傳遞需要時間，所以「離使用者近一點」會是很直覺的考量。AWS 的網路延遲介紹也把傳輸距離列為影響因素。

從地圖上的臺灣出發，東京就在附近；美國維吉尼亞北部位於美國東部，隔著太平洋，距離遠多了。圖上的線用來比較地理遠近，實際網路走哪條路，還要另外確認。

訊息在網路上傳遞的等待，就是我們在談的網路延遲。今天比較的是訊息送出去、回應再回來，這一趟花了多久。

你可能會看到 ms 這個單位，它是毫秒，1,000 毫秒等於 1 秒。例如 30ms 是 0.03 秒，200ms 是 0.2 秒。用同樣方式比較這段來回時間時，數字越小，代表等待越短。

整理成一張 Region 評量表

看到這裡，可能會覺得：「只是選主機放哪裡，想不到還要考量上面的細節」

來分享一個簡易的評估表。從上往下看，先確認能不能用，再比較自己在意的事。

上面三列，要能回答到具體問題：所需的服務在這裡能不能用？主機與資料的位置符合要求嗎？用相同需求估算後，每月費用有沒有超過上限？

如果客戶要求主機留臺灣，國外方案就在這一步先排除。不能替它的價格和速度各加十分，最後說「總分比較高，所以還是選國外」。那個不能違反的條件，不會因為其他項目表現好就消失。

等必要條件都符合，再看圖下面的選擇。小型 MVP 想先省錢，可以以費用優先；如果這次比較在意使用者少等一點，就比較測得的連線時間。先說好這次在意什麼，再看哪個方案符合。

舉個假設：A 方案每月 US$24、來回 30ms；B 方案每月 US$20、來回 200ms。兩個都符合所需功能與資料要求，也都在 US$30 的預算內。

假設這次說好「預算內，選等待時間較短的」，我們就會選 A。因為兩個都沒超過預算，接著比的是 30ms 和 200ms。B 便宜 US$4 是事實，但這一次最後用來決定的是連線等待。

如果另一位同事也選 A，卻只說「我記得那裡比較近」，這個理由還不完整。要能說出功能、資料位置和預算都過關，也有相同方式量到的結果，才能知道下次條件變動時該怎麼重選。

靈魂拷問：換你來想想看～

以前我在寫前後端的時候，通常都是照著規格寫，需要時再擴充程式架構，後來接觸雲端後才發現很多項目都是取捨問題，沒有最佳解，只有當下最適合的作法

所以之後的章節都會嘗試放些申論題，幫助大家可以拿題目去思考、或者是請 AI 給你延伸你想瞭解的話題，希望大家會喜歡 :D

題目如下：

這次請你當一個小型活動團隊的工程師。團隊想先做報名網站的 MVP，第一批會員都在臺灣：會員註冊後收一封驗證信，完成驗證，再報名活動。網站會保存會員資料，每月雲端費用最多 US$30。

你打算用 EC2 執行網站程式，用 SES 寄驗證信。資料怎麼保存，後面的文章再慢慢介紹；今天先決定這些東西能放在哪裡。

接下來，假設我們帶著這個網站，和客戶、同事一起討論主機要放哪裡。每次討論的條件有點不同，這三題我不放標準答案，你可以先寫下自己的判斷和理由，最後再找 AI 陪你延伸思考。

第一題：更便宜，也更快，就可以換嗎？

第一次開需求會議，客戶明確要求：「這個網站的主機、會員資料和備份，都必須留在臺灣，合約會寫清楚。」

同事拿出一個日本方案：「假設這個方案比較便宜，測試結果也比較快，把整個網站和資料放過去，不是兩全其美嗎？」

你會讓他直接採用嗎？評量表裡，哪一格還沒過關？

如果同事改口：「那主機留臺灣，只有會員資料和備份放日本呢？」你的回答會不會變？

第二題：開會資料準備好了，還缺什麼？

接著，假設客戶重新確認需求，同意修改合約：這個網站的主機、會員資料、備份與寄信服務，都可以放在日本或美國。有了這個新的前提，我們才開始比較東京與美國維吉尼亞北部。

這份提案另外說好：每個候選方案的 EC2、會員資料、備份與 SES，都放在所選的同一個 Region。 也就是選東京，就集中在東京；選美國維吉尼亞北部，就集中在那裡。前面提過的跨區寄信方式，這份提案沒有採用。

下一次開會，同事準備了這些資料：

同事說：「主機能開、錢也夠，那就可以讓會員收驗證信，順順地報名了吧？」

你會請他補哪兩項資料？他已經準備的東西，又有哪些可以先留下來，不必重查？

第三題：先做 MVP，這次要把錢花在哪裡？

沿用第二題「每個方案的服務集中在同一個 Region」的安排。同事補齊資料後，確認兩地都有網站需要的功能，位置要求也符合。臺灣會員試用兩個方案後，團隊認為這一版的等待時間都能接受。

下面是這個練習的比較表。費用與時間都是假設數字，不是 AWS 報價或實測結果。

團隊原本考慮「預算內，選等待最短的」。但討論第一版的目標後，改成：「先看看有沒有人願意用。既然兩個方案都符合要求、試用也能接受，這次就選每月費用最低的。」

照最後說好的規則，你會選哪裡？如果之後改成優先縮短等待，選擇會怎麼變？

小結

下次有人問「網站要放哪個 Region」，可以先聊聊：使用者在哪裡、需要什麼功能、主機和資料有哪些限制、預算多少，以及這一版最在意什麼。

很多事情都有取捨。想少花一點錢，可能就要接受多等一下；客戶要求主機留臺灣，選擇的範圍也會跟著縮小。

沒有一個永遠最好的方案，而是根據當下的需求、限制和資源，找到這個階段最適合的解法。 等使用者、預算或要求改變

希望這篇文章對你有幫助 :D

下一篇，我們接著聊另一個問題：如果怕主機壞掉，所以準備了兩台，把它們放在一起就能放心了嗎？